Data as a Product vs. Data as a Service

The difference between providing “data” and providing “insights” (actually though)

WTF do data teams even do?

The job of an engineering team is to build effective, scalable products according to spec. The job of a product team is to understand and build solutions for users. What’s the job of a data team?

There’s no one or clear answer, which helps explain why the field is such a complete shit show right now. There are two broad mandates that data teams tend to get formed with (I’m being overly simplistic on purpose, bro):

1) Provide data to the company

2) Provide insights to the company

These might sound similar — and they’re certainly both important — but they necessitate completely different skillsets. In fact, I’m going to argue that the conflation of these two objectives is exactly what kills good data talent and confounds the hiring process.

Data as a Product: DaaP

Data as a Product is the simplest model to understand: the job of the data team is to provide the data that the company needs, for whatever purpose, be it making decisions, building personalized products, or detecting fraud. This might just sound like data engineering, but it’s not: Data Scientists also provide data as a product, just packaged in a different way.

In the DaaP model, company data is viewed as a product, and the data team’s role is provide that data to the company in ways that facilitate good decision making and application building. Some important characteristics of this model:

• Data has an SLA (figuratively) from the entire data team, not just data engineering
• Data flow is unidirectional, from the data team to the company
• Domain expertise has limited benefits for data team members

This model is not new at all, is a staple of what BI teams do at big companies like Microsoft, and isn’t going anywhere. But there’s no such…